メインコンテンツまでスキップ

特定の車両タイプの場所へのアクセス制限 (Restricting access of certain vehicle types to locations)

ユースケース: 特定の車両タイプに対する場所へのアクセス制限 (Use Case: Restricted Access for Specific Vehicle Types to Locations)​

ロジスティクス運用では、特定の車両タイプが特定の場所にアクセスするのを制限する必要があることがよくあります。この機能は、運用効率の維持、安全規制の遵守、およびインフラストラクチャ制限の管理に不可欠です。

スペースの制約とそこで扱われる商品の種類により、小型のバンや軽トラック専用に設計された専用の積み込みドックがある配送センターのシナリオを考えてみましょう。同時に、同じ配送センターには、小型のドックには不適切な大型トラックや連結大型トラック用の、別のより大きなヤードと積み込みベイがある場合があります。

SWAT を使用すると、特定の車両タイプに関連付けることで、場所の制限を定義できます。ルートを最適化する場合、システムは許可されたタイプに一致する車両のみがこれらの場所に誘導されるように自動的に保証します。これにより、運用上のボトルネックや潜在的な損傷を防ぎ、サイト固有のルールの遵守も保証します。この機能により、アクセスを厳密に制御しながら、複雑な物流ネットワーク内での多様なフリートタイプのシームレスな統合が可能になります。

実装 (Implementation)​

場所へのアクセスを管理するために、SWAT は構造化された VehicleType モデル を導入しています。

VehicleType モデル: 中央テンプレート (The VehicleType Model: A Central Template)​

この機能の核となるのは、新しい VehicleType モデル です。これを車両を作成するための再利用可能なテンプレートと考えてください。プロジェクト内で定義する各 VehicleType は、次のようなデフォルトプロパティのセットを指定できます。

  • 車両タイプ名 (例: 'small_van')
  • ルーティングプロファイルと設定
  • 容量構造
  • コストプロファイル
  • 関連する labels のセット

車両の作成: 作成時にコピー (Creating Vehicles: Copy on Create)​

新しい Vehicle を作成して VehicleType に関連付けると、システムは 「作成時にコピー (copy on create)」 アプローチを使用します。

  • 仕組み: 車両のプロパティ (容量やコストなど) は、作成時に VehicleType からコピーされます。
  • なぜ便利なのか: これにより柔軟性が得られます。テンプレートに基づいて事前構成された車両を取得しますが、元の VehicleType テンプレートを変更することなく、後でその特定のプロパティをオーバーライドまたは変更できます。

車両ラベルの集約方法 (How Vehicle Labels are Aggregated)​

車両のラベルの最終的なセットは、ジョブや場所にマッチングさせるために重要ですが、次の3つのソースから自動的に集約されます。

  1. VehicleType 名 自体 (例: 'heavy_truck')。
  2. VehicleType で定義された追加のラベル (例: 'refrigerated', 'tail-lift')。
  3. 作成中または作成後に Vehicle インスタンス自体で指定するラベル。

たとえば、ラベル 'urgent_delivery' を持つ車両を作成し、ラベル 'high_capacity' を持つ 'large_van' という名前の VehicleType に割り当てた場合、最終的な車両には 'large_van'、'high_capacity'、および 'urgent_delivery' の3つのラベルすべてが含まれます。

OperationsLoCationVehicleType モデル による場所の制限​

特定の OperationsLocation にサービスを提供できる車両のタイプを直接制御できるようになりました。これは、シミュレーション、車両タイプ、および運用場所自体を含む3方向リンクを通じて行われます。運用場所に明示的に接続された車両タイプのみが、その場所への訪問を許可されます。

シミュレーションはこの3方向接続の一部であるため、これらの制限は各シミュレーションに固有です。計画の柔軟性をさらに高めるために、これらの制限は simulation 内で一時的に調整することもできます。これにより、プランナーは場所のマスターデータを変更することなく、さまざまなシナリオ（たとえば、1回限りのイベントのために場所でより大きなトラックを許可するなど）を試すことができます。 さらに、これらの制約は、シミュレーションテンプレート レベルで定義できます。このように設定すると、関係はそのテンプレートから作成されたすべての新しいシミュレーションに自動的にコピーされます。

ヒント

内部的には、システムは自動的に labels を生成します。これらのラベルは、運用場所と車両に対して作成され、車両はそのタイプに基づいて決定されます。

ラベルを組み合わせるロジック (The Logic of Combining Labels)​

予約を制限された場所にルーティングする必要がある場合、システムは予約の要件と場所の制限をインテリジェントに組み合わせます。最終的なルールは、論理的な AND で2つの条件セットを結合することによって作成されます。

これは、車両が予約の元のラベル要件 と 場所の許可されたタイプの 両方 を満たす必要があることを意味します。

詳しく見てみましょう。

  1. 予約要件: 予約には、booking.vehicle_labels で定義された独自の複雑なラベル要件セットを含めることができます。

    • 例: 予約には、ラベル '1'、'2' または '3' の少なくとも1つを持ち、同時に '5' と '6' の両方を持たない車両が必要です。ロジックは次のようになります。 
      {"and": ["1", {"or": ["2", "3"]}, {"not": {"and": ["5", "6"]}}]}

  2. 場所の制限: 場所の allowed_vehicle_types は、論理的な OR 条件に変換されます。

    • 例: 場所はタイプ 'small_van' または 'light_truck' の車両を許可します。ロジックは次のようになります。 
      {"or": ["small_van", "light_truck"]}

  3. 最終的な結合ロジック: システムは AND を使用してこれら2つのルールを組み合わせます。結果の node.vehicle_labels では、車両がすべての条件を満たす必要があります。

    • 最終的な例: 
      {
        "and": [
          {"and": ["1", {"or": ["2", "3"]}, {"not": {"and": ["5", "6"]}}]},
          {"or": ["small_van", "light_truck"]}
        ]
      }

これにより、ルーティングが正確であることが保証されます。割り当てられた車両は、ジョブに必要な特定の機器または属性（ルール1）を持っているだけでなく、物理的にその場所にアクセスすることも許可されています（ルール2）。